しがないOLのはじめての「Microsoft Access」　～テーブル構成を考える編～

しがないOLのはじめての「Microsoft Access」

#バックオフィス

#Microsoft Access

くにきち

2011.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。胃弱なクニ吉です。

前回に引き続き、MicrosoftのAccessについて書きます。

今回は、早速テーブル作成・・・と行きたいところですが、その前にどういう構成でテーブルを作るかを考える必要があります。これは前回書いたように一番重要なところで、アプリケーションの使い勝手を左右すると考えています。私は設計を勉強したわけでもなく、とりあえず手を動かしてやってみました。しかし、考えてテーブルを設定したつもりでも、ちゃんと作ってみないといいのか悪いのかが分からず、フォームまで作った後に設定し直したりと結構大変でした＾＾；テーブル同士を紐づけたり（リレーション設定）、フォームを作ったり、データを入れてしまうと直すのがほんっと！めんどくさいです。（手戻り作業は大抵面倒なものですけど。。。）

今回は私がどのように設定したかをお伝えして、テーブル構成のヒントになればいいなと思います。

必要な情報を考え、書き出す

では、まず自分が管理している（したい）情報を書き出しましょう。どういった情報が必要なのかは自分を含む全利用者の視点で検討する必要があります。アプリケーション全体だとボリュームが大きいですし、かといって何もないのは分かりづらいので、今回は「取引先情報テーブル」を作成することをゴールとします。

ここで、前提としてどういう条件で使用するのかを整理します。

◆前提条件

管理範囲：クニ吉が管理している3セクションの取引先情報　※当時は営業部、マーケ、購買の3つ
管理する目的：取引先コードの管理/閲覧、書類送付や各種問合せのための企業および担当者情報の管理/閲覧
データ入力者：クニ吉のみ（でも将来的には他の人が使う可能性あり？）
データ閲覧者：主に営業、経理、クニ吉
抽出したいレポート：取引先コード一覧、担当者情報一覧
その他：クニ吉は複数部署の事務管理をしているが、管理が他部署に移る可能性がある。

このように前提条件を書き出すことによって、想定していなかった項目が洗い出される場合があります。管理項目の漏れをなくすのに役立ちますので必ず行ってください。

私は上記前提をもとに以下のように書き出しました。

取引先コード　※書類番号として使用するために設定
管理部署　　　※データ抽出や事務管理が他部署になった時のデータ移行を容易にするために設定
会社名
会社名フリガナ
住所
部署名
役職
担当者名
担当者名フリガナ
メールアドレス
電話番号
FAX番号
備考

書き出した情報をどう構成するかを考える

ここで私が考えたのが、「どう構成したら一番入力回数が少なく済むか？」ということでした。本来であれば、取引先情報として①取引先コード～⑬備考までは同じテーブルでも問題はないのかもしれません。しかし、前回の「Accessってなに？編」でお伝えしたように、Accessの利点であり、そもそもこのアプリケーションを作成する目的のひとつとして「同じデータを入力する手間が省ける（＝作業時間の短縮）」というのがありました。会社名はもちろんのこと、”同じ部署で関係者が何人もいる”というのはざらでしたので、私はあえて顧客情報のテーブルをいくつかに分けることにしました。社内のエンジニアに「使い勝手はもちろん、のちのちの修正や機能追加の可能性、データ移行などを考えると、ひとつのテーブルをあまり大きくしない方がいい」というアドバイスがあったのも理由のひとつです。